Automatic delivery traffic indication message interval control for better mobile power save performance

ABSTRACT

The present disclosure discloses a method and network device for automatic delivery traffic indication message (DTIM) interval control for better mobile power save performance. The disclosed network device determines one or more characteristics for at least one client device connected to an Access Point (AP). The network device then dynamically selects a DTIM interval for the AP based on the characteristics for the at least one client device, and configures the AP to transmit a DTIM beacon frame at a frequency based on the dynamically selected DTIM interval. Alternatively, the network device can determine one or more characteristics for a client device, and dynamically select a Virtual Access Point (VAP) for providing network access to the client device based on the characteristics for the client device and a DTIM interval configured for the VAP, and then cause the client device to connect to the VAP.

This application is a continuation of U.S. application Ser. No.14/169,896 filed Jan. 31, 2014, issued as U.S. Pat. No. 9,332,497, thecontents of which are incorporated herein by reference.

FIELD

The present disclosure relates to power management of wireless clientsin a wireless local area network. In particular, the present disclosurerelates to automatic delivery traffic indication message (DTIM) intervalcontrol for better mobile power save performance.

BACKGROUND

Wireless digital networks, such as networks operating under the currentElectrical and Electronics Engineers (IEEE) 802.11 standards, arespreading in their popularity and availability. In a wireless local areanetwork (WLAN) deployment, a number of clients can be connected to thesame wireless network via one or more access points. The number and typeof smart phones, tablets, laptops and other clients that connect toWLANs continues to rise as new generations of clients hit the market.Such diverse clients with different operating systems and WLAN chipsetsoften result in a variety of connection speeds, roaming behaviors, bandpreferences, and other capabilities.

Different wireless devices have very different power saving strategiesand profiles. Such power saving strategies vary with factors, such asdevice make, device configuration, change in usage patterns, type oftraffic being used (e.g., whether the traffic is broadcast, multicast,or unicast), etc. For example, in a tablet device where the user isactively browsing web data, the device will sleep less often. A deliverytraffic indication message (DTIM) informs the clients about the presenceof buffered multicast/broadcast data on the access point. It isgenerated within the periodic beacon at a frequency specified by theDTIM Interval. Every sleeping device on a wireless access point (AP)wakes up at least every DTIM interval to check if there are any pendingbroadcasts or multicast frames that the AP has buffered for it. This isthe time the device has to wake up irrespective of whether the AP hasbuffered pending unicast frames for the station. In case of devices withless active usage, it is not very useful for the devices to wake up sooften to check for pending multicast traffic. On the other hand, someclient devices may wake up more frequently. Therefore, DTIM intervalcontrol is important for maintaining performance of wireless network forclient devices, and at the meantime assuring that the client deviceshave good power save performance. The DTIM interval is typicallyconfigured in terms of number of beacons. For example, if the DTIMinterval is configured as 3, then every third beacon will be consideredas a DTIM beacon.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure may be best understood by referring to thefollowing description and accompanying drawings that are used toillustrate embodiments of the present disclosure.

FIG. 1 is a diagram illustrating an exemplary wireless networkenvironment according to embodiments of the present disclosure.

FIG. 2 is a diagram illustrating exemplary virtual access pointsaccording to embodiments of the present disclosure.

FIG. 3 illustrates exemplary communication frames transmitted by APand/or client devices during power save mode according to embodiments ofthe present disclosure.

FIGS. 4A-4B illustrate exemplary processes for automatic DTIM intervalcontrol according to embodiments of the present disclosure.

FIG. 5 illustrates a system for automatic DTIM interval controlaccording to embodiments of the present disclosure.

DETAILED DESCRIPTION

In the following description, several specific details are presented toprovide a thorough understanding. While the context of the disclosure isdirected to power save management in wireless network, one skilled inthe relevant art will recognize, however, that the concepts andtechniques disclosed herein can be practiced without one or more of thespecific details, or in combination with other components, etc. In otherinstances, well-known implementations or operations are not shown ordescribed in details to avoid obscuring aspects of various examplesdisclosed herein. It should be understood that this disclosure coversall modifications, equivalents, and alternatives falling within thespirit and scope of the present disclosure.

Overview

Embodiments of the present disclosure relate to virtual broadcastdomains in a wireless local area network. In particular, the presentdisclosure relates to overlaying one or more virtual broadcast domainsor groups on an underlying physical network in a wireless local areanetwork.

With the solution provided herein, the disclosed network device receivesa broadcast message from a member device (e.g. a client device that is amember) of a broadcast group. The broadcast group includes a subset ofdevices sharing at least one common property. The member device canreceive a broadcast or multicast message from other member devices, butnot from a non-member device of the first broadcast group. Furthermore,the broadcast group includes one of (I) a subset of devices from asingle virtual local area network, and (ii) at least two subsets ofdevices from two or more virtual local area networks. The network devicethen determines the broadcast group associated with the receivedbroadcast message based on the common property, and then transmits thereceived broadcast message to other member devices in the broadcastgroup.

Computing Environment

FIG. 1 shows an exemplary wireless digital network environment accordingto embodiments of the present disclosure. FIG. 1 includes a router 120that connects a wireless local area network (WLAN), e.g., WLAN 100, andInternet 140. WLAN 100 also includes at least a management networkdevice, e.g., controller 110, which connects a plurality of networkdevices, such as access points AP1 130, AP2 135, etc., through wired orwireless connections. Each access point (AP) further provides wirelessservices to a number of client devices. As illustrated in FIG. 1, clientdevices 160-164 are associated with AP1 130; and, client device 168 isassociated with AP2 135.

The network depicted in FIG. 1 may operate on a private networkincluding one or more local area networks. The local area networks maybe adapted to allow wireless access, thereby operating as a wirelesslocal area network (WLAN). In some embodiments, one or more networks mayshare the same extended service set (ESS) although each networkcorresponds to a unique basic service set (BSS) identifier. In addition,network depicted in FIG. 1 may include multiple network control planedevices, such as network controllers, access points or routers capableof controlling functions, etc.

During operations, a wireless station, such as client devices 160,client device 164, or client device 168, is associated with a respectiveaccess point, e.g., access point AP1 130, access point AP2 135, etc. TheAPs may periodically transmit a beacon frame to announce the bufferedbroadcast and/or multicast packets to the client devices at a fixedinterval period (e.g., DTIM interval period). Each client device wakesup at the fixed interval period to listen for the AP's beacon frame andreceive the broadcast and/or multicast messages. In addition, eachclient may wake up one or more times during the interval period toreceive unicast messages buffered at the AP for the specific clientdevice.

FIG. 2 is a diagram illustrating exemplary virtual access pointsaccording to embodiments of the present disclosure. A virtual accesspoint (VAP) is a logical entity that resides within a physical accesspoint (AP). To a client, the VAP appears as an independent access pointwith its own unique service set identifier (SSID). In the exampleillustrated in FIG. 2, Access Point 1 200 and Access Point 2 230 are twophysical access points.

Each of them is configured with a unique SSID. For example, Access Point1 200 is configured with SSID₁, and Access Point 1 200 is configuredwith SSID₂. Each AP can have multiple radios. For example, Access Point1 200 has two radios R1 210 and R2 215. Access Point 2 230 has tworadios R1 240 and R2 245. Each radio can be configured to advertise itsown VAP with unique extended service set identifier (ESSID). Forexample, R1 210 of Access Point 1 200 is configured as Virtual AccessPoint 1 220 with ESSID₁; R2 215 of Access Point 1 200 is configured asVirtual Access Point 2 225 with ESSID₂; R1 240 of Access Point 2 230 isconfigured as Virtual Access Point 3 250 with ESSID₃; R2 245 of AccessPoint 2 230 is configured as Virtual Access Point 4 255 with ESSID₄;etc. According to embodiments of the present disclosure, each VAP can beconfigured with a different DTIM interval.

DTIM Interval Control

A delivery traffic indication message (DTIM) informs the clients aboutthe presence of buffered multicast/broadcast data on the access point.It is generated within the periodic beacon at a frequency specified bythe DTIM Interval. According to the IEEE 802.11 standards, a DTIM periodvalue generally is a number that determines how often a beacon frameincludes a Delivery Traffic Indication Message. This number is includedin each beacon frame transmitted by an access point (AP) to indicate tothe client devices whether the AP has buffered broadcast and/ormulticast data waiting for them. Following a beacon frame that includesa DTIM, the AP will release the buffered broadcast and/or multicastdata, if any exists. The higher the DTIM period, the longer a clientdevice may sleep and therefore the more power that particular clientdevice may potentially save.

Client devices in wireless networks may have conflicting requirementsfor power consumption and communication throughput when in power-savemode. For example, laptop computers may require relatively highcommunication throughput and may have low sensitivity to powerconsumption. Therefore, a relatively low DTIM period, for example 1, maybe suitable for these devices. Pocket devices, however, may requirerelatively low communication throughput and may be operated by batteriesof relatively low capacity. Therefore, a higher DTIM period, for example8, may be suitable for pocket devices. But some of these have a mediumto high communication throughput, while still having small batteries, sowould benefit from a medium DTIM period, such as 4.

FIG. 3 illustrates exemplary communication frames transmitted by APand/or client devices during power save mode according to embodiments ofthe present disclosure. AP 300 periodically transmits a beacon 330 at afixed interval. In addition, AP 200 transmits a DTIM beacon 340 at aless frequent interval (e.g., every 3 beacon intervals). Client 1 310and Client 2 320 wake up at the less frequent interval (e.g., every 3beacon intervals) to listen for DTIM beacon 340. In addition, eachclient wakes up at different frequencies in between DTIM beacons 340 tocheck for buffered unicast messages for a specific client (e.g., client1 310 or client 2 320).

Metric for Client Sleep Pattern

According to embodiments of the present disclosure, a client sleeppattern metric can be calculated for every client on a VAR The clientsleep pattern metric generally refers to a measure of the client'scurrent sleep activity as seen from null data frames or any other framessent by the client, which indicates a transition in power save state.This sleep activity duty cycle can be computed as the fraction of thenumber of times the client changes power management state in theDTIM_max time to the DTIM_Max interval. The DTIM_max time generally isthe product of the beacon interval and the maximum setting for the DTIMinterval.

For example, if the DTIM_Max interval is 5 beacon intervals, then theDTIM_max time is 500 milliseconds with a 100 millisecond beaconinterval. Thus, if the client changes power management state 15 timesduring the 500-millisecond time period, then the client sleep patternmetric could be computed as 15/5=3. This client sleep pattern metricindicates that on an average the client wakes up about 3 times perbeacon interval. Hence, such a client would function best with an AP orVAP that has a DTIM interval configured close to 1 beacon interval (theminimum configurable value). On the other hand, if the client wakes uponly 3 times during the 500-millisecond time period, then the clientsleep pattern metric could be computed as 3/5=0.6. Hence, the DTIMinterval on the AP or VAP that would best suit such a client is1/client-sleep-pattern-metric=1/0.6, which is approximately 2.

In some embodiments, all client power save states are maintained in adriver of a network device on a per-station basis. The network devicewould also compute and maintain a sleep duty cycle for each client. Thisclient sleep pattern metric is a single metric that captures theaggressiveness of a client device's power management mechanism, and thetraffic load from the client device. In other embodiments, the sleeppattern metric could be optionally computed and maintained on any entityin the network or in the cloud from where the DTIM interval of any APcould be configured.

Match AP's DTIM Interval to Clients' Power Save Profile

There are three basic ways to match an AP's DTIM interval to a clientdevice's power save profile: (1) steer client devices to best AP basedon the AP's DTIM interval using Aruba ClientMatch™ technology; (2)dynamically recalibrate DTIM for each AP and/or VAP; and/or (3) a hybridapproach that combines both (1) and (2).

A. Steer Client Devices to Match AP's DTIM Interval

The first approach steers client devices to match the APs' DTIMintervals. Based on the client sleep pattern metric, a target DTIMsetting can be calculated as 1/client-sleep-pattern-metric. This1/client-sleep-pattern-metric can be exponentially averaged over aperiod of time for every client. Using this information, clients can besteered to the appropriate APs, radios, and/or VAPs. For example, if aclient's sleep pattern metric is 3, the client will be steered to beassociated with an AP or a VAP that has a DTIM interval configured closeto 1 beacon interval. As another example, if the client sleep patternmetric is 0.6, the client will be steered to be associated with an AP ora VAP that has a DTIM interval configured close to 2 beacon intervals.

B. Dynamic Recalibration of AP's DTIM Interval

The second approach dynamically recalibrates an AP or VAP's DTIMinterval based on sleep pattern metrics of the client devices associatedwith the AP or VAP. For example, the AP or VAP's DTIM interval can beconfigured as a number between 1 (or the minimum DTIM value) and 5 (themaximum DTIM value). The minimum and maximum DTIM values are the onesthat will not cause significant performance deterioration and will beconfigurable. The system will then compute an average interval valueTimeAvg based on (1/client-sleep-pattern-metric) for every client. Theseinterval values can be weighted across clients based on the type ofdevice (e.g., whether the client device is recognized as a mobile deviceor power critical device) to generate a weighted average DTIM intervalvalue. Using this information, the DTIM interval on the VAP profile canbe recalibrated every so often to match the power profile of theclients. The dynamic recalibration of DTIM interval allows the system todetermine how frequently clients associated with an AP or VAP prefers towake up, and adjust the AP or VAP's DTIM interval configuration so thatthe clients are not forced to wake up to listen to multicast orbroadcast frames more frequently than they would like.

Moreover, the DTIM interval can also be dynamically adjusted based onhow much traffic clients associated with an AP or VAP have. For example,when a few clients associated with a particular AP or VAP are performingnetwork intensive operations that generate a large amount of traffic,the system may adjust the DTIM interval for the particular AP or VAP toa short value. Subsequently, when those clients complete the operationsand other clients prefer to wake up less frequently based on theirclient sleep pattern metrics, the system can dynamically adjust toreduce the DTIM interval of the particular AP or VAP.

In addition, the DTIM interval can be dynamically adjusted based on thepresence and/or absence of a particular client device and/or user roles,etc. For example, if a VIP client device is associated with an AP, theAP's DTIM interval may be adjusted to match the VIP client device'spreference.

Furthermore, the characteristics for the at least one client deviceindicate a current level of power remaining in a battery of the at leastone client device. For example, when the current level of powerremaining in the client battery is low, a long DTIM interval may beselected to help the client preserve its battery level.

Moreover, the DTIM interval can also be dynamically adjusted based on acurrent time. The current time generally refers to time of day, day ofweek, etc. For example, during night time when network usage is low, arelatively long DTIM interval may be selected. On the other hand, duringwork hours when network usage is high, a relatively short DTIM intervalmay be selected.

C. Hybrid Sleep Pattern Matching

In the hybrid approach, the system mixes both of the above approachesfor achieving superior performance. Hence, depending on the networkconditions, the system might optionally change the DTIM interval on theVAP/radio and/or it might also decide to move clients. In one embodimentwith the hybrid approach, the system only moves client devices to otherAPs or VAPs when it is known with certainty that the client devices arenot fairly active. In some embodiments, when the system justre-calibrated a VAP's DTIM; and, there is a huge discrepancy in thetarget DTIM interval value for the client device from the re-calibratedDTIM interval value currently set on the VAP, the system will steer theclient device away to another VAP with a DTIM that is closer to theclient device's target DTIM interval value. Additional care could betaken with the DTIM interval adjustment to ensure that within a certaingeographic location, there are at least a few numbers of APs or VAPswith different DTIM intervals configured. This will make sure that whenthe system moves the clients, there are multiple options for clients tomove.

Processes for Automatic DTIM Interval Control for Better Mobile PowerSave Performance

FIGS. 4A-4B illustrate exemplary processes for automatic DTIM intervalcontrol according to embodiments of the present disclosure.Specifically, FIG. 4A illustrates an exemplary process for Duringoperations, the disclosed network device determines one or morecharacteristics for at least one client device connected to a firstAccess Point (AP) (operation 400). The network device then dynamicallyselects a Delivery Traffic Indication Message (DTIM) interval for thefirst AP based on the characteristics for the at least one client device(operation 420). The network device further configures the first AP totransmit a DTIM beacon frame at a frequency based on the dynamicallyselected DTIM interval (operation 440).

In some embodiments, the network device dynamically selects the DTIMinterval for a first Virtual Access Point (VAP) of one or more VAPsexecuting on the first AP. In some embodiments, the network devicedynamically selects the DTIM interval for a first radio of one or moreradios of the first AP.

In some embodiments, the characteristics for the at least one clientdevice indicate a frequency with which the at least one client deviceenters a power save mode, and/or a frequency with which the at least oneclient device exits a power save mode.

In some embodiments, the characteristics for the at least one clientdevice are determined based on monitoring of the at least one clientdevice during a period of time between transmissions of DTIM beaconframes. For example, the network device can monitor the number of NULLQoS frames that were sent by a client device during the period of timebetween transmissions of DTIM beacon frames. The NULL QoS frame containsno data but a set of flags, which include a power save bit indicatingwhether the client device enters or exits the power save mode.

In some embodiments, the characteristics for the at least one clientdevice indicate an amount of data transmitted by the at least one clientdevice over a period of time and/or an amount of data transmitted to theat least one client device over the period of time. For example, if alarge amount of data is being transmitted to and/or by the at least oneclient device, the network device may configure its DTIM interval to arelatively short interval. On the other hand, if no data or very limiteddata is being transmitted to and/or by the at least one client device,the network device may configure its DTIM interval to a relatively longinterval.

In some embodiments, the characteristics for the at least one clientdevice indicate a type of data typically transmitted by the at least oneclient device. In some embodiments, the characteristics for the at leastone client device indicate which applications are currently executing onthe at least one client device. For example, if the client device isexecuting an application that frequently transmits or receives data, ashort DTIM interval may be selected.

In some embodiments, the characteristics for the at least one clientdevice indicate a current level of power remaining in a battery of theat least one client device. For example, when the current level of powerremaining in the client battery is low, a long DTIM interval may beselected to help the client preserve its battery level.

In some embodiments, the DTIM interval is dynamically selected basedfurther on a current time. The current time generally refers to time ofday, day of week, etc. For example, during night time when network usageis low, a relatively long DTIM interval may be selected. On the otherhand, during work hours when network usage is high, a relatively shortDTIM interval may be selected.

Whereas multiple radios of an AP are configured as multiple VirtualAccess Points (VAPs), the network device also dynamically selects DTIMinterval values for the respective VAPs executing on the first AP basedon characteristics associated with a plurality of client devicesconnected to at least one of the VAPs executing on the first AP.

Moreover, FIG. 4B illustrates an exemplary process for matching a clientdevice to an AP or VAP. During operations, the disclosed network devicedetermines one or more characteristics for at least one client device(operation 460). Moreover, the network device dynamically selects afirst Virtual Access Point (VAP) from a plurality of VAPs, for providingnetwork access to the at least one client device, based at least on thecharacteristics for the at least one client device and a DeliveryTraffic Indication Message (DTIM) interval configured for the first VAP(operation 470). Also, the network device will cause the at least oneclient device to connect to the first VAP (operation 480). The networkdevice may do so by using Aruba ClientMatch™ technology to intelligentlysteer the client to a desired AP, radio, and/or VAP on the WLAN.

Note that, the characteristics for the at least one client deviceindicate one or more of: frequency with which the at least one clientdevice enters a power save mode; a frequency with which the at least oneclient device exits a power save mode; an amount of data transmitted bythe at least one client device over a period of time; an amount of datatransmitted to the at least one client device over the period of time; atype of data typically transmitted by the at least one client device;which applications are currently executing on the at least one clientdevice; a current level of power remaining in a battery of the at leastone client device; etc.

System for Automatic DTIM Interval Control

FIG. 5 is a block diagram illustrating a system for automatic DTIMinterval control according to embodiments of the present disclosure.

Network device 500 includes at least one or more radio antennas 510capable of either transmitting or receiving radio signals or both, anetwork interface 520 capable of communicating to a wired or wirelessnetwork, a processor 530 capable of processing computing instructions,and a memory 540 capable of storing instructions and data. Moreover,network device 500 further includes a receiving mechanism 550, atransmitting mechanism 560, a determining mechanism 570, and a selectingmechanism 580, all of which are in communication with processor 530and/or memory 540 in network device 500. Network device 500 may be usedas a client system, or a server system, or may serve both as a clientand a server in a distributed or a cloud computing environment.

Radio antenna 510 may be any combination of known or conventionalelectrical components for receipt of signaling, including but notlimited to, transistors, capacitors, resistors, multiplexers, wiring,registers, diodes or any other electrical components known or laterbecome known.

Network interface 520 can be any communication interface, which includesbut is not limited to, a modem, token ring interface, Ethernetinterface, wireless IEEE 802.11 interface, cellular wireless interface,satellite transmission interface, or any other interface for couplingnetwork devices.

Processor 530 can include one or more microprocessors and/or networkprocessors. Memory 540 can include storage components, such as, DynamicRandom Access Memory (DRAM), Static Random Access Memory (SRAM), etc.

Receiving mechanism 550 generally receives one or more network messagesvia network interface 520 or radio antenna 510 from a wireless client.The received network messages may include, but are not limited to,requests and/or responses, beacon frames, management frames, controlpath frames, and so on. Each message may comprise one or more datapackets, for example, in the form of IP packets.

Transmitting mechanism 560 generally transmits messages, which include,but are not limited to, requests and/or responses, beacon frames,management frames, control path frames, and so on. In some embodiments,transmitting mechanism 560 is configured to transmit a DTIM beacon frameat a frequency based on a dynamically selected DTIM interval byselecting mechanism 580.

Determining mechanism 570 generally determining one or morecharacteristics for at least one client device connected to an AccessPoint (AP) or Virtual Access Point (VAP). In some embodiments,determining mechanism 570 determines that a client shall be steered toanother AP, radio, and/or VAP; and, cause the client to be connected tothe other AP, radio and/or VAP.

Selecting mechanism 580 generally dynamically selecting a DeliveryTraffic Indication Message (DTIM) interval for the first AP based on thecharacteristics for the at least one client device.

In some embodiments, selecting mechanism 580 dynamically selects theDTIM interval for a first Virtual Access Point (VAP) of one or more VAPsexecuting on the first AP. In some embodiments, selecting mechanism 580dynamically selects the DTIM interval for a first radio of one or moreradios of the first AP. In some embodiments, selecting mechanism 580dynamically selects DTIM interval values for respective Virtual AccessPoints (VAPs) executing on the first AP based on characteristicsassociated with a plurality of client devices connected to at least oneof the VAPs executing on the first AP.

In some embodiments, selecting mechanism 580 dynamically selects a firstVirtual Access Point (VAP) from a plurality of VAPs, for providingnetwork access to the at least one client device, based at least on thecharacteristics for the at least one client device and a DeliveryTraffic Indication Message (DTIM) interval configured for the first VAP.

In some embodiments, selecting mechanism 580 dynamically selects a firstradio from a plurality of radios, for providing network access to the atleast one client device, based at least on the characteristics for theat least one client device and a Delivery Traffic Indication Message(DTIM) interval configured for the first radio;

In some embodiments, the characteristics for the at least one clientdevice indicate a frequency with which the at least one client deviceenters a power save mode and/or a frequency with which the at least oneclient device exits a power save mode.

In some embodiments, the characteristics for the at least one clientdevice are determined based on monitoring of the at least one clientdevice during a period of time between transmission of DTIM beaconframes.

In some embodiments, the characteristics for the at least one clientdevice indicate an amount of data transmitted by the at least one clientdevice over a period of time and/or an amount of data transmitted to theat least one client device over the period of time.

In some embodiments, the characteristics for the at least one clientdevice indicate a type of data typically transmitted by the at least oneclient device.

In some embodiments, the characteristics for the at least one clientdevice indicate which applications are currently executing on the atleast one client device.

In some embodiments, the characteristics for the at least one clientdevice indicate a current level of power remaining in a battery of theat least one client device.

In some embodiments, the DTIM interval is dynamically selected basedfurther on a current time.

The present disclosure may be realized in hardware, software, or acombination of hardware and software. The present disclosure may berealized in a centralized fashion in one computer system or in adistributed fashion where different elements are spread across severalinterconnected computer systems coupled to a network. A typicalcombination of hardware and software may be an access point with acomputer program that, when being loaded and executed, controls thedevice such that it carries out the methods described herein.

The present disclosure also may be embedded in non-transitory fashion ina computer-readable storage medium (e.g., a programmable circuit; asemiconductor memory such as a volatile memory such as random accessmemory “RAM,” or non-volatile memory such as read-only memory,power-backed RAM, flash memory, phase-change memory or the like; a harddisk drive; an optical disc drive; or any connector for receiving aportable memory device such as a Universal Serial Bus “USB” flashdrive), which comprises all the features enabling the implementation ofthe methods described herein, and which when loaded in a computer systemis able to carry out these methods. Computer program in the presentcontext means any expression, in any language, code or notation, of aset of instructions intended to cause a system having an informationprocessing capability to perform a particular function either directlyor after either or both of the following: a) conversion to anotherlanguage, code or notation; b) reproduction in a different materialform.

As used herein, “network device” generally includes a device that isadapted to transmit and/or receive signaling and to process informationwithin such signaling such as a station (e.g., any data processingequipment such as a computer, cellular phone, personal digitalassistant, tablet devices, etc.), an access point, data transfer devices(such as network switches, routers, controllers, etc.) or the like.

As used herein, “access point” (AP) generally refers to receiving pointsfor any known or convenient wireless access technology which may laterbecome known. Specifically, the term AP is not intended to be limited toIEEE 802.11-based APs. APs generally function as an electronic devicethat is adapted to allow wireless devices to connect to a wired networkvia various communications standards.

As used herein, the term “interconnect” or used descriptively as“interconnected” is generally defined as a communication pathwayestablished over an information-carrying medium. The “interconnect” maybe a wired interconnect, wherein the medium is a physical medium (e.g.,electrical wire, optical fiber, cable, bus traces, etc.), a wirelessinterconnect (e.g., air in combination with wireless signalingtechnology) or a combination of these technologies.

As used herein, “information” is generally defined as data, address,control, management (e.g., statistics) or any combination thereof. Fortransmission, information may be transmitted as a message, namely acollection of bits in a predetermined format. One type of message,namely a wireless message, includes a header and payload data having apredetermined number of bits of information. The wireless message may beplaced in a format as one or more packets, frames or cells.

As used herein, “wireless local area network” (WLAN) generally refers toa communications network links two or more devices using some wirelessdistribution method (for example, spread-spectrum or orthogonalfrequency-division multiplexing radio), and usually providing aconnection through an access point to the Internet; and thus, providingusers with the mobility to move around within a local coverage area andstill stay connected to the network.

As used herein, the term “mechanism” generally refers to a component ofa system or device to serve one or more functions, including but notlimited to, software components, electronic components, electricalcomponents, mechanical components, electro-mechanical components, etc.

As used herein, the term “embodiment” generally refers an embodimentthat serves to illustrate by way of example but not limitation.

It will be appreciated to those skilled in the art that the precedingexamples and embodiments are exemplary and not limiting to the scope ofthe present disclosure. It is intended that all permutations,enhancements, equivalents, and improvements thereto that are apparent tothose skilled in the art upon a reading of the specification and a studyof the drawings are included within the true spirit and scope of thepresent disclosure. It is therefore intended that the following appendedclaims include all such modifications, permutations and equivalents asfall within the true spirit and scope of the present disclosure.

While the present disclosure has been described in terms of variousembodiments, the present disclosure should not be limited to only thoseembodiments described, but can be practiced with modification andalteration within the spirit and scope of the appended claims. Likewise,where a reference to a standard is made in the present disclosure, thereference is generally made to the current version of the standard asapplicable to the disclosed technology area. However, the describedembodiments may be practiced under subsequent development of thestandard within the spirit and scope of the description and appendedclaims. The description is thus to be regarded as illustrative ratherthan limiting.

What is claimed is:
 1. A method comprising: determining one or morecharacteristics for at least one client device connected to a firstAccess Point (AP); dynamically selecting a Delivery Traffic IndicationMessage (DTIM) interval for the first AP based on the one or morecharacteristics for the at least one client device; and configuring thefirst AP to transmit a DTIM beacon frame at a frequency based on thedynamically selected DTIM interval, wherein the one or morecharacteristics for the at least one client device indicate one or moreof: a frequency with which the at least one client device enters a powersave mode; a frequency with which the at least one client device exitsthe power save mode; an amount of data transmitted by the at least oneclient device over a period of time; an amount of data transmitted tothe at least one client device over the period of time; a type of datatypically transmitted by the at least one client device; whichapplications are currently executing on the at least one client device;and a current level of power remaining in a battery of the at least oneclient device.
 2. The method of claim 1, wherein dynamically selectingthe DTIM interval for the first AP includes dynamically selecting theDTIM interval for a first Virtual Access Point (VAP) of one or more VAPsexecuting on the first AP.
 3. The method of claim 1, wherein dynamicallyselecting the DTIM interval for the first AP includes dynamicallyselecting the DTIM interval for a first radio of one or more radios ofthe first AP.
 4. The method of claim 1, further comprising dynamicallyselecting the DTIM interval based on the frequency with which the atleast one client device enters the power save mode or the frequency withwhich the at least one client device exits the power save mode.
 5. Themethod of claim 1, further comprising determining the characteristicsfor the at least one client device, based on monitoring of the at leastone client device during a period of time between transmission of DTIMbeacon frames.
 6. The method of claim 1, further comprising dynamicallyselecting the DTIM interval based on the amount of data transmitted bythe at least one client device over a period of time or the amount ofdata transmitted to the at least one client device over the period oftime.
 7. The method of claim 1, further comprising dynamically selectingthe DTIM interval based on the type of data typically transmitted by theat least one client device.
 8. The method of claim 1, further comprisingdynamically selecting the DTIM interval based on the applications thatare currently executing on the at least one client device.
 9. The methodof claim 1, further comprising dynamically selecting the DTIM intervalbased on the current level of power remaining in a battery of the atleast one client device.
 10. The method of claim 1, further comprisingdynamically selecting the DTIM interval based on a current time.
 11. Themethod of claim 1, further comprising dynamically selecting DTIMinterval values for respective Virtual Access Points (VAPs) executing onthe first AP based on characteristics associated with a plurality ofclient devices connected to at least one of the VAPs executing on thefirst AP.
 12. A network device comprising a non-transitory computerreadable medium comprising instructions executable by a hardwareprocessor to: determine one or more characteristics for at least oneclient device; select a first Virtual Access Point (VAP) from aplurality of VAPs, for providing network access to the at least oneclient device, based on the one or more characteristics for the at leastone client device and a Delivery Traffic Indication Message (DTIM)interval configured for the first VAP, wherein the DTIM interval isdetermined based on a frequency that the at least one client deviceenters a power save mode; and cause the at least one client device toconnect to the first VAP.
 13. The network device of claim 12, whereinthe one or more characteristics for the at least one client deviceindicate one or more of: the frequency with which the at least oneclient device enters the power save mode; a frequency with which the atleast one client device exits the power save mode; an amount of datatransmitted by the at least one client device over a period of time; anamount of data transmitted to the at least one client device over theperiod of time; a type of data typically transmitted by the at least oneclient device; which applications are currently executing on the atleast one client device; and a current level of power remaining in abattery of the at least one client device.
 14. The network device ofclaim 12, further comprising instructions executable by the hardwareprocessor to select the first VAP from the plurality of VAPs based on afrequency with which the at least one client device exits the power savemode.
 15. The network device of claim 12, further comprisinginstructions executable by the hardware processor to select the firstVAP from the plurality of VAPs based on an amount of data transmitted bythe at least one client device over a period of time or an amount ofdata transmitted to the at least one client device over the period oftime.
 16. A non-transitory computer readable medium comprisinginstructions executable by a hardware processor to: determine a numberof changes to a power management state of a client device during aperiod of time; determine a client sleep pattern metric for the clientdevice as a fraction of the number of changes to a maximum deliverytraffic indication message (DTIM) interval; match a virtual access point(VAP) DTIM to the client sleep pattern metric by dynamicallyrecalibrating a DTIM interval for the VAP based on the sleep patternmetric of the client device; wherein the client device is among aplurality of client devices associated with the VAP, and wherein theinstructions to dynamically recalibrate the DTIM interval includeinstructions executable by the hardware processor to: determine anaverage interval value for each respective client device among theplurality of client devices; and determine a weighted average DTIMinterval for the VAP using the determined average interval values. 17.The non-transitory computer readable medium of claim 16, wherein theinstructions to match a VAP DTIM to the client sleep pattern metricinclude instructions executable by the hardware processor to select aVAP from a plurality of VAPs for the client device based on thedetermined client sleep pattern metric.
 18. The non-transitory computerreadable medium of claim 16, wherein the client device is among aplurality of client devices and the instructions to match the DTIM tothe client sleep pattern metric include instructions executable by thehardware processor to, for each client device among the plurality ofclient devices: select a VAP from a plurality of VAPs for the clientdevice based on the DTIM interval of the VAP and the sleep patternmetric of the client device; or dynamically recalibrate a DTIM intervalfor a VAP associated with the client device, based on the determinedclient sleep pattern metric for the client device.